IP networks were originally designed to carry “best effort” traffic where the network makes a “best attempt” to deliver a user packet, but does not guarantee that a user packet will arrive at the destination. Because of the market success of IP networks, there is a clear requirement for mechanisms that allow IP networks to support various types of applications. Some of these applications have Quality of Service (QoS) requirements other than “best effort” service. Examples of such applications include various real time applications (IP Telephony, video conferencing), streaming services (audio or video), or high quality data services (browsing with bounded download delays). Recognizing these QoS requirements, the Internet Engineering Task Force (IETF), which is the main standards body for IP networking, standardized a set of protocols and mechanisms that enable IP network operators to build QoS-enabled IP networks.
FIG. 1 depicts a simplified high-level model of an IP network accessed by end users via associated access networks which may be useful in explaining QoS provisioning. As can be appreciated, the model includes two users, but could easily be expanded to include more users without changing the basic functionality of the network. In FIG. 1, User-A 10 may communicate with User-B 12 or with an application server 13. For example, in the case of an IP telephony session, User-A 11 may communicate with User-B 12. Similarly, in the case of streaming services, User-A 11 may communicate with the application server 13, which may be configured as a video server. In either case, User-A 11 accesses an IP backbone network 14 through a local access network 15, such as PSTN (dial-in access), Global System for Mobile Communications (GSM), or Universal Mobile Telecommunications System (UMTS) network. User-B 12 is similarly connected to the IP network 14 through a local access network 16. Of particular interest to this invention is the specific case where at least one of the access networks is a UMTS or GSM/GPRS network. However, User-A and User-B need not use the same type of access network. The IP network 104 may consist of a number of IP routers and interconnecting links that together provide connectivity between the IP network's ingress and egress points and thereby make two party communication possible. As far as the users are concerned, the QoS depends on both of the access networks 15, 16 and on the IP backbone network 14.
QoS is particularly important for multimedia type communications between a mobile host and a remote host in which a “session” established between the mobile and remote hosts includes two or more different forms of media that often require different types of QoS, e.g., voice, e-mail, video, etc. Consider the example, simplified data communications system shown in FIG. 2 which permits a Mobile Terminal (MT) 20 to initiate and conduct a multimedia session with a remote host 30. The remote host 30 can be a fixed or wireless device. The mobile terminal 20 is coupled to a radio access network (RAN) 22 over the radio interface. The RAN 22 is coupled to an Access Point in packet-switched access network (PSAN) 24, which in turn is coupled to a Packet Data Network (PDN) 28, e.g., the Internet, to which the remote host 30 is coupled. The basic traffic flow for a multimedia session (shown as solid lines) between the mobile terminal 20 and remote host 30) is transported via these three networks 22, 24, and 28. The PSAN 24 and the PDN 28 communicate multimedia control signaling (shown as dashed lines) to a Multimedia System 26 that can be separate from or an integral part of the Packet Data Network 28.
Various user applications may access network services through an application programming interface (API). An API provides application programmers with a uniform interface to access underlying system resources. For instance, an API may be used to configure a network resource manager to require that a particular IP packet originating from a given application receive a certain treatment from the network, such as a particular QoS. For example, if the IP network is a Differentiated Services IP network, then an application program may request that all of its IP packets receive the “Expedited Forwarding” treatment.
The User (and the API in the user's equipment) may not be aware of the different technologies that various access networks and IP backbone networks employ in order to provide QoS end-to-end, i.e., from User-A all the way to remote User-B. For instance, the application program may use an RSVP/IntServ based API, and the end-to-end embodiment in which he is involved may include a UMTS access network and a non-RSVP enabled IP network. In such cases, some “interworking” mechanisms between such different technologies and protocols are needed to make sure that the QoS is provided end-to-end.
Integrated Services (IntServ) provides a set of well-defined services which enables an application to choose among multiple, controlled levels of delivery service for their data packets. To support this capability, two things are required. First, individual network elements, such as subnets and IP routers, along the path followed by an application's data packets must support mechanisms to control the quality of service delivered to those packets. Second, a way to communicate the application's requirements to network elements along the path and to convey QoS management information between network elements and the application must be provided.
IntServ defines a number of services such as Controlled-Load (defined in IETF RFC 2211) and Guaranteed (defined in IETF RFC 2212). The service definition defines the required characteristics of the network equipment in order to deliver the service. The individual network elements (subnets and IP routers) that support the service must comply with the definitions defined for the service.
The service definition also defines the information that must be provided across the network in order to establish the service. This function may be provided in a number of ways, but it is frequently implemented by the resource reservation setup protocol RSVP (defined in IETF RFC 2205). RSVP (Resource reSerVation Protocol) is an IP-level resource reservation setup protocol designed for an IntServ-enabled Internet (defined in IETF RFC 1633, 2205, and 2210). The RSVP protocol is used by a host (e.g., User A's computer) to request specific service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service requests to all nodes along the path(s) of the flows and to establish and maintain the state(s) to provide the requested service. RSVP requests generally result in resources being reserved in each node along the data path.
In a Differentiated Services network, an “edge router” is at the network boundary, and a “core router” is within the network. The edge and core routers have different duties. The edge router must “condition” the traffic to ensure that it conforms to a service agreement, and marks traffic with the appropriate DSCP (Differentiated Services Code Point). It then forwards each packet according to the service behavior defined for that DSCP. The service behavior, called the Per Hop Behavior (PHB) may define the prioritization or weighting of that traffic to give it better service than other traffic. The core nodes examine the DSCP and apply per hop service behavior appropriate for that service.
To realize a QoS Service with clearly defined characteristics and functionality, a QoS bearer must be set up from the source to the destination of the service. A bearer is a logical connection between two entities through one or more interfaces, networks, gateways, etc., and usually corresponds to a data stream or data flow. A QoS bearer service includes all aspects to enable the provision of a contracted QoS. These aspects include control signaling, user plane transport, and QoS management functionality.
Mobile Radio Access Data Networks, like General Packet Radio Service (GPRS) and Universal Mobile Telecommunication System (UMTS), may form a part of the overall network and will typically be a significant factor in the end-to-end bearer service for customers connected to it. Hence, the bearer service over a GPRS/UMTS network is important to achieving the required end-to-end bearer service.
The GPRS/UMTS network includes a set of network elements between the host, referred to as the Mobile Station (MS), and an external packet switching network the user is connecting to like the Internet. These network elements are shown in FIG. 3. The radio access network (RAN) provides access over the radio interface to/from the mobile station (MS) host. The RAN is coupled to a Serving GPRS Support Node (SGSN) and a Gateway GPRS Support Node (GGSN). The GGSN provides the interworking with external packet-switched networks, e.g., the Internet.
Before a mobile host can send packet data to a remote host, the mobile host must “attach” to the GPRS network to make its presence known and to create a packet data protocol (PDP) context. The PDP context establishes a relationship with a GGSN towards the external network that the mobile host is accessing. The PDP attach procedure is carried out between the mobile host and the SGSN to establish a logical link. As a result, a temporary logical link identity is assigned to the mobile host. A PDP context is established between the mobile host and a GGSN selected based on the name of the external network to be reached. One or more application flows (sometimes called “routing contexts”) may be established over a single PDP context through negotiations with the GGSN. An application flow corresponds to a stream of data packets distinguishable as being associated with a particular host application. An example application flow is an electronic mail message from the mobile host to a fixed terminal. Another example application flow is a link to a particular Internet Service Provider (ISP) to download a graphics file from a website. Both of these application flows are associated with the same mobile host and the same PDP context. User data is transferred transparently between the MS and the external data networks with a method known as encapsulation and tunneling: data packets are equipped with PS-specific protocol information and transferred between the MS and the GGSN.
Quality of Service (QoS) has an extremely important and central role in 3rd generation (3G) UMTS mobile networks, especially for multimedia sessions. QoS is a means for providing end users with satisfying service. QoS also enables efficient use of the spectrum resources. Because the invention will be described in terms of a UMTS QoS architecture, a brief overview of QoS in UMTS is provided. The 3G UMTS QoS architecture is described, including an explanation of the packet data protocol context (PDP context), a traffic flow template (TFT), and the QoS maintenance procedures for activated UMTS bearers. It is expected that the QoS characteristics associated with a radio communication are the most critical in the end-to-end chain. Within UMTS access networks, the radio network resources are managed on a per PDP context level, which corresponds to one or more user flow/data streams and a certain QoS level.
The QoS framework for 3G networks is specified in the 3G specification (3GPP) TS23.107. The main focus is on the QoS architecture to be used in the UMTS level, where the list of QoS attributes applicable to UMTS Bearer Service and the Radio Access Bearer Service are specified along with appropriate mapping rules. TS23.060 specifies the general mechanisms used by data packet connectivity services in the UMTS level, which includes the General Packet Radio Service (GPRS) in GSM and UMTS.
In a UMTS QoS Architecture, a network service is considered to be end-to-end, from a Terminal Equipment (TE) to another TE. To realize a certain end-to-end QoS, a bearer service with clearly defined characteristics and functionality is set up from the source to the destination of a service. Again, the bearer service includes those aspects needed to enable the provision of a contracted QoS, e.g., control signaling, user plane transport, QoS management and functionality.
A UMTS bearer service layered architecture is depicted in FIG. 5. Each bearer service on a specific layer offers its individual services using services provided by the layers below. Bearers at one layer are broken down into underlying bearers, each one providing a QoS realized independently of the other bearers. Service agreements are made between network components, which are arranged horizontally in FIG. 4. The service agreements may be executed by one or more service layers. For instance, the UMTS bearer service consists of a Radio Access Bearer (RAB) service and a Core Network (CN) bearer service. The RAB service is then divided into a radio bearer service and a Iu bearer service. The Iu interface is the interface between the radio access network and the core network.
The following are examples of the entities shown in FIG. 4. The terminal equipment (TE) may be a laptop and the mobile terminal (MT) may be a cellular radio handset. The UTRAN may be made up of a combination of radio base stations called Node B's and radio network controllers (RNCs). The Core Network (CN) Iu Edge Node may be a serving GPRS support node (SGSN), and the CN Gateway may be a gateway GPRS support node (GGSN).
The QoS management functions in UMTS are used to establish, modify, and maintain a UMTS Bearer Service with a specific QoS, as defined by specific QoS attributes. The QoS management functions of all the UMTS entities ensure provision of the negotiated UMTS bearer service. The UMTS architecture comprises four management functions in the control plane and four in the user plane. The four control plane management functions are shown in FIG. 5:                Bearer Service (BS) Manager sets up, controls, and terminates the corresponding bearer service. Each BS manager also translates the attributes of its level to attributes of the underlying bearer service during service requests.        Translation function converts between external service signaling and internal service primitives including the translation of the service attributes, and is located in the MT and in the CN Gateway.        Admission/Capability control determines whether the network entity supports the specific requested service, and whether the required resources are available.        Subscription Control determines whether the user has the subscription for the bearer being requested.The four user plane management functions shown in FIG. 6:        Classification function resides in the GGSN and in the MT. It assigns user data units (e.g. IP packets) received from the external bearer service from the remote terminal (or the local bearer service) from the local terminal to the appropriate UMTS bearer service according to the QoS requirements of each user data unit. This is where a traffic flow template (TFT) and packet filters are situated, as described below.        Mapping function marks each data unit with the specific QoS indication related to the bearer service to which it has been classified. For example, it adds different service code points to packets before putting them on the Iu or CN bearer.        Resource Manager distributes its resources between all bearer services that are requesting use of these resources. The resource manager attempts to provide the QoS attributes required for each individual bearer service. An example of resource manager is a packet scheduler.        Traffic conditioner is a shaping and policing function which provides conformance of the user data traffic with the QoS attributes of the concerned UMTS bearer service. This resides in the GGSN and in the MT as well as in the UTRAN.        
The QoS management functions of the UMTS bearer service maintain the data transfer characteristics according to the commitments established by the UMTS bearer service control functions, expressed by the bearer service attributes. The user plane uses the QoS attributes. The relevant attributes are provided to the user plane management functions by the QoS management control functions.
Four different QoS classes standardized in UMTS are shown in FIG. 7. Data transport may be optimized for the corresponding type of application data or for a bearer service of a certain class. The main distinguishing factor between these classes is how delay sensitive the traffic is: Conversational class is meant for traffic which is very delay sensitive (for real-time services) while Background class is the most delay insensitive traffic class (for non-real time services). Bit error/packet loss rate is also a significant difference between the classes.
To characterize a bearer service in detail, a set of bearer service attributes are standardized in UMTS. FIG. 8 shows which example attributes might be applicable to which example traffic class. FIG. 9 provides an overview of uses for different QoS attributes. The exact definitions of QoS attributes can be found in TS23.107. A certain QoS is requested by selecting a set of attribute values that describes the bearer requirement. Parameters differ depending on the type of bearer service requested.
A UE subscription is associated with one or more Packet Data Protocol (PDP) addresses, i.e., IP addresses in the case of IP traffic. Each PDP address is described by one or more PDP contexts stored in the MS, the SGSN, and the GGSN. Default values are also available in the cellular system database, e.g., the HLR, which holds the subscription information. Each PDP context may be associated with a Traffic Flow Template (TFT). A Traffic Flow Template is a packet filter (or set of filters) that associates packets to the correct PDP context thereby ensuring that packets are forwarded with correct QoS characteristics. The relationship between PDP address, PDP context, and TFT is shown in FIG. 10. The TFT enables the possibility of having several PDP contexts with varying QoS profiles to be associated with a single PDP address. The TFT is managed and initiated by the MT both for the uplink and downlink flows. The uplink TFT resides in the MT, while the downlink TFT resides in the GGSN. The downlink TFT is sent from the MT to the GGSN during PDP context activation/modification.
A PDP context is implemented as a dynamic table of data entries having all needed information for transferring PDP PDUs between MS and GGSN, e.g., addressing information, flow control variables, QoS profile, charging information, etc. The relation between UMTS bearer services and PDP context is a one-to-one mapping, i.e., if two UMTS bearer services are established for one PDP address, two PDP contexts are defined. The PDP context procedures are standardized in TS23.060.
Because there are several data flows corresponding to the different communications media employed in a multimedia session, each data flow is supported by a PDP context in the UMTS network which ensures a certain quality of service for the data flow. Namely, a specific transport channel transporting such a flow will have sufficient resources to support that requested quality of service. However, before these data flows and supporting PDP contexts/bearers can be established for the multimedia session, a UE must first request the multimedia session to be set up, and a number of signaling operations over a signaling bearer must be performed. In addition to session setup services, there are also ongoing session signaling needs, (e.g., for streaming services), that must be transmitted over a signaling bearer. Even though there are quality of service classes already established for radio access bearers to support different types of data flows in a multimedia session, the characteristics for a UMTS signaling/radio access bearer are not optimally satisfied by any of the already-established quality of service classes. In this regard, the characteristics of an optimal signaling UMTS/radio access bearer are as follows:                low bit error ratio        bursty traffic pattern        low delay time (to provide short session setup times)        high priority (even to the point where it may be possible to permit signaling traffic to take priority over user traffic)        
None of the established quality of service classes for traffic well satisfies all of these QoS requirements for signaling. For example, a conversational class does not provide the low bit error ratio and is not appropriate for bursty traffic. A streaming class does not provide low bit error ratio and low delay, and is also not appropriate for bursty traffic. A background class, although it may meet the low bit error ratio requirement and is appropriate for bursty traffic, does not provide the low delay and high priority requirements. An interactive class provides low bit error ratio and is appropriate for bursty traffic. But to achieve low delay would require network dimensioning and scheduling on the interactive bearer in order to be achieved. Nor is the high priority requirement satisfied since the traffic handling priority parameter of the interactive class only allows priority to be defined within the interactive traffic class; it does not allow priority over other traffic classes, e.g., conversational or streaming traffic classes.
Moreover, it is also desirable for network operators to permit UMTS signaling bearers to be handled differently once established. For example, an operator may want to provide multimedia signaling bearers free of charge to encourage users to set up multimedia sessions. In this circumstance, it may be desirable to restrict the usage of a signaling UMTS bearer to only sending session initiation protocol signals to a particular destination such as a multimedia system control server. This is useful in at least two instances. First, if an operator does not charge for a signaling UMTS bearer, such restrictions do not allow a user to improperly use a “free” UMTS signaling bearer for data traffic. Second, the quality of service established for a signaling bearer, as noted above, is quite rigorous, and it may well not be the most economical use of resources for typical multimedia data flows. Alternatively, there may be situations where an operator may want to offer a signaling quality of service for use with a normal traffic bearer, perhaps with an extra surcharge.
The present invention overcomes the problems set forth above and meets the above-identified objectives. A signaling bearer quality of service profile is pre-established and configured in various nodes in an access network. This is a new quality of service (QoS) class designed to meet the needs of signaling bearers in multimedia sessions that involve a plurality of media data streams. A message requesting a bearer to support communication between a mobile terminal and an access point to a packet data network is generated. That message includes a signaling QoS indicator, which when detected, causes a bearer to be established between the mobile terminal and the access point in accordance with the pre-established signaling QoS profile. In one preferred, non-limiting, example embodiment, the bearer is a signaling bearer restricted to carrying signaling information relating to the session. In other, example, non-limiting embodiments, the signaling QoS profile may be employed in setting up media packet access bearers.
The pre-established signaling QoS profile typically includes both low delay and low bit error rate quality of service characteristics. Additional QoS characteristics might include high priority and accommodation of a bursty traffic pattern. Indeed, a high priority QoS characteristic may even permit the bearer to take priority over already established bearers. One of the benefits of the signaling QoS profile being already configured in the nodes in an access network is the quality of service for such a bearer requesting that signaling QoS profile need not be negotiated during the setup of the session, as is typically the case. Although it may be desirable for signaling bearers to have such a signaling bearer quality of service profile, if the signaling QoS indicator is not set in the bearer request message, a signaling bearer may be established with some other quality of service class/profile.
In order to control access to and use of the signaling quality of service profile, a further aspect of the present invention permits restricting use of a bearer with the pre-established signaling QoS profile. Such restriction may ensure that only signaling packets are transported over the signaling bearer, and that traffic packets are blocked from transport over the signaling bearer. This restriction may be indicated/activated using a signaling usage indicator included in the bearer request/setup message (or in some other message) that may be separate from the signaling QoS indicator. Restrictions may be implemented using packet filters at the access point node. Another example restriction is to identify a bearer source and a bearer destination of packets for the bearer established with the signaling QoS profile. Only those packets from the identified source to the identified destination are transported over the bearer. One example of source and destination includes the mobile terminal and a multimedia system server. Other restrictions and options may also be implemented/associated with the signaling usage indicator. In one non-limiting, example embodiment, the signaling usage indicator may be included in a protocol configuration options (PCO) parameter associated with the PDP context setup message.
A preferred example application is to a UMTS/GPRS access network. The UMTS/GPRS access network is coupled to an IP network such as the Internet. The session bearer request is in the form of a PDP context request message. A PDP context extends from a mobile terminal across the UMTS/GPRS access network to a GGSN node that is coupled to the Internet. The signaling QoS indicator included in such a PDP context request message may be detected in an SGSN node as well as a radio network controller (RNC). Each of RNC, SGSN, and GGSN nodes may store the pre-established signaling QoS profile before any sessions are requested. In addition, each of these nodes may be configured with a standard set of bearer capabilities associated with the signaling QoS profile.